home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Internet Tools 1995 April / Internet Tools.iso / dos_win / lanman / drivers / dos / UBNEPS / UBNEPSD.ZIP / README.TXT < prev    next >
Encoding:
Text File  |  1991-09-05  |  9.8 KB  |  173 lines
  1. ;        Sample PROTOCOL.INI for UBNEPS
  2. ;        ------------------------------
  3. ;   This is a sample PROTOCOL.INI file for the Ungermann-Bass NDIS MAC driver
  4. ; for NICps/2 cards ("UBNEPS").  The [UBNEPS] section shows examples of UBNEPS
  5. ; configuration parameter settings. Comments at the end of the file explain
  6. ; these parameters and give their default, minimum and maximum values.
  7. ;   The [protocol manager] and [netbeui] sections aren't meant to be complete
  8. ; or realistic examples, except for the "BINDINGS = UBNEPS" line in the
  9. ; [netbeui] section.
  10. ;
  11. ;[protocol manager]
  12. ;    DRIVERNAME = PROTMAN$
  13. ;
  14. ;[netbeui]
  15. ;    DRIVERNAME = NETBEUI$
  16. ;    BINDINGS = UBNEPS
  17. ;    SESSIONS = 32
  18. ;    NCBS = 100
  19. ;
  20. ;[UBNEPS]
  21. ;    Note that many of these parameters have default values (which are
  22. ; given below under "Comments about UBNEPS parameters"). A parameter need not
  23. ; be specified in your PROTOCOL.INI if its default value is satisfactory.
  24.     DriverName = UBNEPS$
  25. ;    SlotNumber = 4
  26.     MaxTransmits = 6
  27. ;    TransmitBuffers = 2
  28.     ReceiveBufSize = 600
  29.     MaxMulticast = 16
  30.     ReceiveMethod = ReceiveLookahead
  31.     ReceiveBuffers = 64
  32.  
  33. ;  Comments about UBNEPS parameters:
  34. ;  --------------------------------
  35. ;  DriverName:
  36. ;        This parameter's value must be UBNEPS$, or, in the case where
  37. ;    multiple adapters are installed, UBNEPS$ for the first adapter's
  38. ;    DriverName, UBNEPS2$ for the second one, UBNEPS3$ for the third, and
  39. ;    so on.
  40. ;  SlotNumber:            (Min = 1; Max = 8.)
  41. ;        This parameter is needed only when multiple NICps/2 adapters, and
  42. ;    multiple instances of the UBNEPS driver, are installed.  Even then,
  43. ;    this parameter is required only if it is necessary to override the
  44. ;    default association between driver instances and adapters. By default,
  45. ;    the UBNEPS driver instance that comes first in PROTOCOL.INI will be
  46. ;    associated with the NICps/2 adapter in the lowest numbered slot, the
  47. ;    UBNEPS driver instance that comes second will be associated with the
  48. ;    NICps/2 adapter in the second lowest numbered slot, and so on.
  49. ;  MaxRequests:            (Default = 6; Min = 1; Max = 10.)
  50. ;        This specifies the maximum number of "GeneralRequest"s that can be
  51. ;    simultaneously outstanding.
  52. ;  MaxTransmits:        (Default = 8; Min = 1; Max = around 400.)
  53. ;        This specifies the number of "TransmitChain"s that the MAC driver
  54. ;    guarantees to accept without giving an "OUT_OF_RESOURCE" response.
  55. ;  TransmitBuffers:        (Default = 2; other choice = 4.)
  56. ;        This specifies the number of transmit buffers that will be
  57. ;    allocated in the adapter's memory.
  58. ;  MaxMulticast:        (Default = 16; Min = 0; Max = 255.)
  59. ;        This specifies the maximum number of multicast addresses that can
  60. ;    be in effect simultaneously. (NOTE that there's no 's' on the end of
  61. ;    this keyword.)
  62. ;  ReceiveBufSize:        (Default = 600; Min = 256; Max = 1514.)
  63. ;        This specifies the size of the receive buffers the MAC driver will
  64. ;    use. This should be large enough to hold the normal expected received
  65. ;    frame. It need not be large enough to hold the largest expected frame.
  66. ;    The MAC driver will handle large frames in multiple receive buffers.
  67. ;    The value of ReceiveBufSize must be even.
  68. ;  ReceiveMethod:    (Default = ReceiveLookahead;
  69. ;             other choices:    ReceiveChain, AdapterBuffered
  70. ;             and        ReceiveChain, HostBuffered
  71. ;        This determines the method of received frame delivery the MAC
  72. ;    driver will use. The possibilities are described below. Which one
  73. ;    is best to use depends mainly on how the Protocol driver you're using
  74. ;    works.  Use number (1) if you don't know anything about the Protocol
  75. ;    driver.
  76. ;   (1) ReceiveMethod = ReceiveLookahead
  77. ;        When a received frame is available and Indications are On, the
  78. ;    MAC driver will call the Protocol driver's "ReceiveLookahead" routine.
  79. ;    "ReceiveLookahead" will be given the total length of the frame and a
  80. ;    pointer to the "lookahead" data in a receive buffer in the adapter's
  81. ;    RAM. The Protocol driver must copy the frame (possibly using the MAC's
  82. ;    "TransferData" routine) before returning from "ReceiveLookahead". When
  83. ;    "ReceiveLookahead" returns, the MAC driver frees the receive buffers
  84. ;    in the adapter's RAM for use in receiving more frames.
  85. ;        This method works well if the Protocol driver is able to copy the
  86. ;    frame to the Protocol driver's client's buffers at the time "Receive-
  87. ;    Lookahead" is called.  It is also a good method if the Protocol driver
  88. ;    always copies frames into internal buffers of its own.
  89. ;   (2) ReceiveMethod = ReceiveChain, AdapterBuffered
  90. ;        When a received frame is available and Indications are On, the MAC
  91. ;    driver will call the Protocol driver's "ReceiveChain" routine, passing
  92. ;    it an "RxBufDescr" which points to the frame in the receive buffers in
  93. ;    the adapter's RAM. The Protocol driver can either (a) immediately copy
  94. ;    the frame or (b) save a copy of the "RxBufDescr" and leave the frame
  95. ;    in the buffers in the adapter's RAM, to be copied at a later time. In
  96. ;    case (b), the Protocol driver must copy the frame as soon as possible
  97. ;    and call the MAC's "ReceiveRelease" function to make the buffers in
  98. ;    the adapter's RAM available for receiving more frames.
  99. ;        This method of operation can be the most efficient.  It's a little
  100. ;    better than the "ReceiveLookahead" method if the Protocol driver can
  101. ;    copy the frame immediately, because the overhead of calling "Transfer-
  102. ;    Data" is avoided.  Also, it has the advantage over "ReceiveLookahead"
  103. ;    that the Protocol driver doesn't have to copy the frame immediately --
  104. ;    the frame can be left for a short time in the adapter's buffers. But
  105. ;    if frames are left in the adapter's buffers long, it will run out of
  106. ;    buffers and start losing frames. Also, there's the overhead of calling
  107. ;    "ReceiveRelease" to consider.
  108. ;   (3) ReceiveMethod = ReceiveChain, HostBuffered
  109. ;        When a received frame is available and Indications are On, the MAC
  110. ;    driver will copy the frame from the receive buffers in the adapter's
  111. ;    RAM into receive buffers in the Host memory and call the Protocol
  112. ;    driver's "ReceiveChain" routine, passing it an "RxBufDescr" which
  113. ;    points to the Host-memory buffers.  The Protocol driver can copy the
  114. ;    frame immediately or leave it in the Host-memory buffers.  It must
  115. ;    eventually call the MAC driver's "ReceiveRelease" routine to free the
  116. ;    Host-memory buffers for reuse.  The buffers in the adapter's RAM are
  117. ;    made available for receiving more frames as soon as "ReceiveChain"
  118. ;    returns.
  119. ;        In this mode, the MAC driver allocates receive buffers in the Host
  120. ;    memory.  These buffers are allocated at driver INIT time. Their number
  121. ;    and size are determined by the "ReceiveBuffers" and "RcvBufSize" para-
  122. ;    meters.  The only advantage of this mode is that in it the MAC driver
  123. ;    provides a possibly large amount of long-term frame buffering in which
  124. ;    a Protocol driver can leave received frames until it can deliver them
  125. ;    to its clients.  This advantage comes at the cost of the space devoted
  126. ;    to the Host-memory buffers.  This is an inefficient mode if the
  127. ;    Protocol driver always copies frames into its own internal receive
  128. ;    buffers or if it can quickly copy frames from the adapter's buffers to
  129. ;    its client's buffers.
  130. ;  ReceiveBuffers:        (Default = 32; Min = 16; Max = 512.)
  131. ;        This specifies the number of receive buffers that the MAC driver
  132. ;    will allocate in the Host memory.  This parameter is meaningful only
  133. ;    if "ReceiveMethod = ReceiveChain, HostBuffered" is specified.  For
  134. ;    other values of "ReceiveMethod", no receive buffers will be allocated
  135. ;    in the Host memory -- the "ReceiveBuffers" parameter will be ignored.
  136. ;  PermanentAddr:    The value is a string of 12 ASCII hexadecimal digits,
  137. ;            for example:    PermanentAddr = "00DD01AABBCC"
  138. ;        This parameter provides a way to override the "Permanent Station
  139. ;    Address" that's built into the adapter's ROM. Note that this parameter
  140. ;    is normally not needed, and shouldn't be used.  The NDIS specification
  141. ;    strongly discourages configuring the "Permanent Station Address".
  142. ;
  143. ;  How Much Host Memory UBNEPS Uses
  144. ;  --------------------------------
  145. ;       You can compute the amount of PC memory UBNEPS will use. It depends
  146. ;    on the "ReceiveMethod" you select and on the values you choose for the
  147. ;    "MaxRequests", "MaxTransmits", "MaxMulticast", "ReceiveBuffers", and
  148. ;    "ReceiveBufSize" parameters.  The total space used will be the sum of
  149. ;    the following five items.
  150. ;   (1)    For driver code and data:  10210 (2566 data + 7644 code)
  151. ;   (2) For request queueing:       16 + MaxRequests * 22
  152. ;   (3)    For transmit queueing:       16 + (MaxTransmits - TransmitBuffers) * 146
  153. ;   (4)    For multicast addresses:    4 + (MaxMulticast * 16)
  154. ;   (5)    For receive buffers:       16 + ReceiveBuffers * (ReceiveBufSize + 8)
  155. ;    Item (5) does not apply unless you use "ReceiveMethod = ReceiveChain,
  156. ;    HostBuffered".  Item (3) does not apply if the value of "MaxTransmits"
  157. ;    is less than or equal to the value of "TransmitBuffers".
  158. ;        The total you compute may not be exactly correct but it should be
  159. ;    close.  The reasons for inexactness are: (a) the value for item number
  160. ;    (1) will vary with different versions of the drivers; and (b) the
  161. ;    other items may take up a little more space than the formulas imply,
  162. ;    because of the need to allocate buffers and other data structures at
  163. ;    doubleword-aligned or paragraph-aligned boundaries.
  164. ;        Under DOS, all the space used by the driver is allocated in one
  165. ;    contiguous piece.  It will be in "conventional" memory (that is, in
  166. ;    the first 640K) if the driver is loaded by a normal "DEVICE=" line in
  167. ;    CONFIG.SYS, or in "upper" memory (above 640K) if the driver is loaded
  168. ;    by "DEVICEHIGH=" or by "LOADHI".  Note that if the total memory used
  169. ;    is large (because of a large value for item (5)), there may not be
  170. ;    room to load the driver into "upper" memory.
  171. ;        Under OS/2, item (1) is allocated in low memory, and the other
  172. ;    items are allocated in high memory if possible.
  173.